![[アップデート] AWS License ManagerでRemote Desktop Services SAL (RDS SAL)の単体購読が可能になりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-30c6b35929ef670a60a9af9866c8c381/e5c69d3837c419569958df6846cd101e/aws-license-manager)
[アップデート] AWS License ManagerでRemote Desktop Services SAL (RDS SAL)の単体購読が可能になりました
2024.11.18しばたです。
先日AWSより AWS launches user-based subscription of Microsoft Remote Desktop Services というタイトルのアナウンスがあり、AWS License ManagerでRemote Desktop Services SAL(RDS SAL)を単体で購読できる様になりました。
更新内容自体はシンプルであるものの、かなりクセのある仕組みなので本記事で解説していきたいと思います。
どういうことか？
以前こちらの記事に書いた様に、これまでAWS License ManagerのユーザーベースサブスクリプションではMicrosoft Office Professional Plus (LTSC)とVisual Studio Pro/Enterpriseを購読可能で、RDS SALは両者とセットで購読するものでした。
このため当時は、
- RDS SALを単体で購読不可
- RD Licensing Serverが無いため1つのEC2インスタンスを3人以上で共用不可
という問題を抱えていました。
今回の更新はこの問題を解消するもので、
- RDS SALを単体で購読可能 (自動購読されるケースがある模様)
- AWS License ManagerがマネージドなRD Licensing Serverを提供して利用者が指定可能
- これにより1つのEC2インスタンスを3人以上で共用可能に
という改善がなされています。
前提条件
今回の更新はざっくり下図のイメージになります。
ディレクトリにAWS Managed Microsoft ADを使った場合の構成
前提条件としてAWS Managed Microsoft ADか利用者がセルフホストするActive Directory環境が必要です。
これまではAWS Managed Microsoft ADが必須でしたが、RDS SALだけ使うのであればセルフホストActive Directoryでも構いません。Viual StudioやMicrosoft Officeを併用するのであればAWS Managed Microsoft ADが必要となります。
AWS License ManagerからRDS SAL購読のための設定を行うとAWSが管理する環境下に2台のWindows Server 2022が作成されRD Licensing Serverとして構成されます。
このRD Licensing Serverが利用者のVPCにENIを延ばすことで実際に利用可能となります。
利用者から見ると新たに「Microsoft RDS ライセンスサーバーエンドポイント」が増え、VPC内部から名前解決可能なホスト名が新たに与えられます。
# Microsoft RDS ライセンスサーバーエンドポイント名の例 : VPC内部からのみ名前解決可
<アカウントID>-<ランダムID>.aws-lm-user-subscriptions-license-server.amazon.com
Remote Desktop Session Host(RDSH)のライセンスサーバーの指定でこのホスト名を選んでやることで実際に利用可能となります。
RDS SALはユーザーライセンスのみの提供ですのでライセンスモードは必ず「接続ユーザー数」にする必要があります。
そして、RDS CAL/SALの互換性により本日時点で利用可能なOSは
- Windows Server 2022
- Windows Server 2019
- Windows Server 2016
のみとなります。
Windows Server 2025はまだ非サポート[1]です。
VPCのDNS設定
前述の通り「Microsoft RDS ライセンスサーバーエンドポイント」が増える形を採るため、VPCの設定で
- DNS 解決を有効化
- DNS ホスト名を有効化
の両方を有効にしておく必要があります。
これらが無効だとエンドポイントの名前解決ができないのでご注意ください。
AWS Secrets Manager設定
この仕組みではAWSがRD Licensing Serverを構築する都合Active Directoryに対するアクセスが発生するので、以下の権限を持ったAcitve Directoryユーザーの認証情報が必要となります。
-
OUの作成権限がある
-
作成したOUに対してコンピューターオブジェクトを追加する権限がある
-
コンピューターを「Terminal servers group」に追加する権限がある
-
「ADドメイン」と「Terminal Server license server (=RD License Server)」内のユーザーオブジェクトに対する委任された読み取り・書き込み権限を保有している
- この権限はライセンスレポートの作成するために必要
比較的強めの権限を必要とする感じです。
厳密にやる場合は上権限を持つ専用ユーザーを新規に用意してやりますが、検証等ではDomain AdminsなユーザーかAWS Managed Microsoft ADであればadminユーザーを選べば良さそうです。
AWS Secrets Managerにこのユーザーの認証情報をしてやり、シークレットの名前は必ずlicense-manager-user-で始まる必要があります。
シークレットにはusernameとpasswordのキーを登録しそれぞれユーザー名とパスワードを保存します。
利用料金
本日(2024年11月17日)時点でRDS SALの利用料金は「一人当たり 10 USD/月 (日割り無し)」でとなります。
この料金自体は以前と変わりませんが、今回新たにSecrets Managerが必要になったのでその維持費は別途かかります。
Secrets Managerへの具体的なリクエスト数は公開されていませんが、流石に10000アクセスは行かないと思うので無視して構わないでしょう。シークレットの維持費 0.40 USD/月 だけで済むと思います。
また、特に明記されていませんでしたが、AWSが作成するRD Licensing Serverの利用費は請求されない様です。
検証期間中に追加請求されることはありませんでした。
注意点
実際に機能を試す前に注意点について触れておきます。
1. RDS SALの利用範囲
そもそもの話として、Client Access License(CAL)とSubscriber Access License(SAL)は別物であり互換性がありません[2]。
簡単に差異を列挙すると次の通りです。
| 項目 | CAL | SAL |
|---|---|---|
| 購入形態 | 基本 買い切り | 毎月のサブスクリプション |
| 購入先/契約先 | Microsoftおよび代理店 | サービス事業者 (今回だとAWS) |
| 利用形態 | Microsoftからライセンスを購入 | 事業者のサービスを利用 |
| 適用対象 | 購入者の環境 (オンプレミス) | サービス事業者の環境 (クラウド等) |
RDS SALはあくまでもSPLAにおいてサービス事業者(ここではAWS)が提供する環境でRemote Desktop Serviceを利用する際に必要となる追加ライセンスであり、AWS以外の環境では利用できないはずです。
たとえばオンプレミス環境や他社クラウド環境にRDSHサーバーを構築し、Site-to-Site VPN等で本機能で作成されるRD Licensing Serverに接続しライセンスを消費する行為は違反になるはずです。
こちらは技術的にはできてしまう[3]のでご注意ください。
2. RDS SALのサブスクリプションは自動購読されることがある
後述する動作確認をしたところ、AWS License Managerでは定期的にRD Licensing Serverの利用状況をチェックし、リモートデスクトップ接続の利用があったユーザーを自動でサブスクリプションに追加する様です。
RDS CAL(SAL)の建付けとしてこの行為は正当なものではありますが、自動購読の判定がかなり厳しい様に見えました。
このため操作ミス等により意図しないサブスクリプション増（利用費増）が起きる可能性があるのでご注意ください。
試してみた
ここからは実際に動作確認した結果を共有していきます。
0. 検証環境
私の検証用AWSアカウントの東京リージョンにVPCを一つ用意し、最初に紹介したイメージ図と同様の構成を作成していきます。
VPCの作成手順は割愛します。
1. AWS Managed Microsoft ADの用意
はじめにActive Directory環境としてAWS Managed Microsoft ADディレクトリを作成します。
今回はマネジメントコンソールからStandardエディションでcorp.contoso.comドメインを作成しています。
特別な設定は不要で特筆する点が無いため構築手順は割愛します。
2. Secrets Manager シークレットの登録
次にSecrets Managerシークレットを用意します。
前述の通り、license-manager-user-で始まる名称でusernameとpasswordをキーに持つ必要があります。
今回は、
- 名前 :
license-manager-user-rdlicense-administrator - ユーザー :
admin([email protected]) - パスワード :
adminユーザーのパスワード
の設定でAWS CloudShellからCLIで作成しておきます。
# AWS License Manager用のシークレットを作成
aws secretsmanager create-secret \
--name "license-manager-user-rdlicense-administrator" \
--description "Secrets for RD License Server local administrator user." \
--secret-string "{\"username\":\"admin\",\"password\":\"P@ssword\"}"
出来上がった結果はこんな感じです。
3. AWS License Managerの設定変更
ここからAWS License Managerの設定を行います。
初回利用時はAWSが内部的に利用するサービスリンクロールの作成を求められるので許可しておいてください。
マネジメントコンソールからAWS License Managerを選び、左ペイン下部にある「設定」→「ユーザーベースのサブスクリプション」を選択します。
初回利用時は最初にAWS MarketplaceにあるRDS SALのサブスクライブを求められるので購読してください。
最初はAWS Marketpalceで製品の購読が必要
RDS SALのサブスクライブが完了すると下図の様になり、Active Directoryの登録が可能になります。
「Active Directoryの登録」ボタンを押すとウィザードが開始されます。
ディレクトの種類を「AWSマネージドActive Directory (AWS Managed Microsoft AD)」か「セルフマネージドActive Directory」から選択可能です。
今回は「AWSマネージドActive Directory」を選び、対象のディレクトリを選んで「登録」ボタンをクリックします。
登録処理が開始され、しばらく待てば登録完了となります。
画面にある通りまだRD Licensing Serverの構築が残っているため、続けて「RDS ライセンスサーバーを設定」ボタンをクリックします。
今度はRD Licensing Server設定ウィザードが開始されるので、「シークレット」に先ほど作成したlicense-manager-user-rdlicense-administratorを指定して「設定」ボタンをクリックします。
ライセンスサーバーの設定が開始されしばらく待つ必要があります。
最終的に「ライセンスサーバーエンドポイントのステータス」が「プロビジョニング済み」になれば完了です。
ちなみにシークレットに登録する認証情報に誤りがあると処理がタイムアウトして失敗するまで1時間近く待たされるのでご注意ください。
(異常に時間がかかる場合は設定ミスを疑うと良いです)
出来上がった設定の詳細について、「Active Direcotry ID」欄をクリックするとディレクトリとの紐づけを確認できます。
「ライセンスサーバーエンドポイントID」をクリックするとRD Licensing Server情報を確認できます。
ここにある「Microsoft RDS ライセンスサーバーエンドポイント」がRD Licensing Serverのホスト名となります。
この時点でVPC内部にこのエンドポイント用のENIが2つ追加されます。
併せてENIに独自のセキュリティグループが追加され、インバウンド許可設定は次の様になっています。
4. ユーザーのサブスクリプションを追加する
次にユーザーを選んでRDS SALの購読を行います。
マネジメントコンソールの左ペインから「ユーザーベースのサブスクリプション」→「製品」の順に選択すると製品の一覧が表示されるので「Microsoft Remote Desktop Services (RDS)」をクリックします。
画面上部に設定完了までのステップが表示されるので、一番右にある「ユーザーをサブスクライブ」をクリックします。
すると購読対象ユーザーの選択画面に遷移するので、ユーザー情報を記入し「次へ」をクリックします。
利用方法の確認画面がでるので内容を確認したうえで「サブスクライブ」をクリックします。
これで購読処理が開始され少し待つと完了します。
追加したユーザー情報は画面下部に表示されます。
5. Remote Desktop Session Host (RDSH)の設定
あとは実際にRDP接続したいRemote Desktop Session Host(RDSH)サーバーを用意してRD Licensing Serverの指定をしてやれば接続可能になります。
基本的な手順としてはこちらの記事にある「1. Active Directory環境にフルインストールする場合」と「2. Active Directory環境にRDSHのみインストールする場合」のパターンを参考にすると良いでしょう。
RDSHからRD Licensing Serverの指定をする際に
- ライセンスサーバー : Microsoft RDS ライセンスサーバーエンドポイント
- ライセンスモード : 接続ユーザー数
にしてやります。
RDS SALはユーザーライセンスのみの提供のため、ライセンスモードは必ず「接続ユーザー数」にしなければなりません。
具体的な手順について決まりは無い[4]様ですが、AWS Managed Microsft ADの場合、Visual StudioとMicrosoft Office AMI向けに専用のグループポリシーLicenseManager Policyが用意されていました。
環境によってはこのポリシーを使っても良いでしょう。
6. 動作確認
今回は用意したVPC上に1台Windows Server 2022 EC2インスタンスを用意しRDSHの機能を追加して動作確認していきます。
細かい手順は割愛しますが、用意したEC2インスタンス(RDSH01)を専用のOU(MyRDSHs)に所属させ前述のLicenseManager Policyを適用しておきました。
この状態でインスタンス内部から「RDライセンス診断機能」を使い適用状況を確認すると期待通りライセンスが適用された状態になりました。
RDSHサーバーのライセンス適用状況
ちなみに、よく見ると利用可能なライセンス数が29,996という異常な数になっています。
管理者ユーザーでRD Licensing Serverに接続しRDS SALの適用状況を見ると「各OSごとに 29,997 (9999 * 3) SAL[5]」が初期設定されていました。
RD Licensing Serverのライセンス登録状況を確認
RDS SALの登録処理は自動化が困難な部分であるため十分な数を初期設定する方式を採用した模様です。
異常な数ですが不具合では無いのでご安心ください。
あと、ディレクトリ内部からMicrosoft RDS ライセンスサーバーエンドポイントに対して名前解決を試みると以下の様に片方のサーバーのIPが返されます。
# Microsoft RDS ライセンスサーバーエンドポイントに対して名前解決
PS C:\> nslookup xxxxxxxxxxxx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.aws-lm-user-subscriptions-license-server.amazon.com
サーバー: ip-c61301d3.corp.contoso.com
Address: 10.0.21.34
権限のない回答:
名前: xxxxxxxxxxxx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.aws-lm-user-subscriptions-license-server.amazon.com
Address: 10.0.21.27
実体となるEC2に対する名前解決の結果は以下の通りです。
具体的な実装方法は不明ですがActive-Standbyで構成されている様です。
# エンドポイントの実体となる2台のEC2に対して名前解決するとこんな感じ
# * 片方がエンドポイントに採用されていることがわかる
PS C:\> nslookup EC2AMAZ-5OF6I1T.corp.contoso.com
サーバー: ip-c61301d3.corp.contoso.com
Address: 10.0.21.34
名前: EC2AMAZ-5OF6I1T.corp.contoso.com
Address: 10.0.21.27
PS C:\> nslookup EC2AMAZ-90SLKCJ.corp.contoso.com
サーバー: corp.contoso.com
Address: 10.0.21.34
名前: EC2AMAZ-90SLKCJ.corp.contoso.com
Address: 10.0.22.77
余談1 : RDS SALの自動購読について
はじめに注意点で解説したとおり、動作検証中にRDS SALが自動的にサブスクライブされた状態になる事象が発生しました。
今回明示的にRDS SALを購読したのは[email protected]ユーザーだけでしたが、最終的には下図の様に3ユーザーサブスクリプションが増える形になりました。
検証作業のなかで[email protected]ユーザーでRDSHサーバーにリモートデスクトップ接続することが何度かあり、いつのまにかサブスクリプションが増え購読状態になっていました。
意図しない購読だったので手動でサブスクリプションを解除しています。
その後、再現チェックのために[email protected]ユーザーで一回だけRDSHサーバーにリモートデスクトップ接続してすぐにログアウト、その後しばらく放置しました。
すると約1時間後くらいにサブスクリプションの購読を開始しはじめ、最終的に購読には至らずキャンセルされました。
どの程度の利用があると自動登録されるのか突き止めることはできませんでしたが、RD Licensing ServerではRDS SALの利用状況を取得できるのでAWSがその内容を定期的に調べているのは確かな様です。
RD Licensing Serverで確認できるRDS SALの利用状況
ちなみに利用費は[email protected]と[email protected]の2人分請求されていました。
記事公開後に改めて確認したら3人全員分請求されてました...どうして...
RDSHに対して管理者がRDP接続する際はmstsc /adminを指定して管理モード接続することが多いと思いますが、うっかり/admin指定を忘れると自動購読の対象になり得るのでご注意ください。
余談2 : RD Licensing Serverの所属OU
AWS Managed Microsoft環境の場合、作成されたRD Licensing Serverは独自の LicenseServer OUに登録されていました。
セルフマネージドActive Directory環境の場合どうなるかは未確認なので後日チェックしたいと思います。
余談3 : Visual StudioやMicrosoft Office環境への影響
今回の更新でRDS SALの購読方法が変わりましたが、Visual StudioとMicrosoft Office環境においてもRDS SALの管理方法が刷新される様です。
既存の環境が無いため動作確認は出来ないのですが、両製品の設定画面を確認すると既存インスタンスの更新方法が記載されていました。
たとえばMicrosoft Officeをサブスクライブするために動作検証と同じAWS Managed Microsoft ADドメインを関連付けるとRD Licesing Serverの設定も一緒に共用される形になりました。
最後に
以上となります。
嬉しい改善ではあるものの使いこなすにはRemote Desktop Serviceに対する知識をかなり求められる印象です。
お気軽に「ライセンスを購読して終わり。」とはいかないのでご注意ください。
また、ライセンスの利用判定がかなり厳しい様なのでこちらも要注意です。
この点に関してはこれまでMicrosoft社のユーザーRDS CAL/SAL運用が紳士協定過ぎた[6]とも言え、AWSの方が本来あるべき型になっているとも言えます。
私は割とRemote Desktop Serviceに慣れ親しんでいるほうですが、そんな私から見ても簡単では無かったので実際に試す際は覚悟しておくとよいでしょう。
RD Licensing Server自体がWindows Server 2025にならないとサポートできないため、実現にはもうしばらく時間を要するでしょう。 ↩︎
互換性がないからこそRDS CALはライセンスモビリティの対象となり"移動"の概念があるとも言えます。 ↩︎
Windows Server側に接続元の環境まで識別する仕組みが無い + 技術的にはCALとSALの区別が無い ↩︎
AWSのドキュメント上は何らかのかたちでグループポリシーを設定する手順が説明されています。 https://docs.aws.amazon.com/license-manager/latest/userguide/usubs-configure-gpo.html ↩︎
OS内部的にはCALとSALは区別されずCALとして表示される ↩︎
ザルとも言う...デバイスCALは厳しめなんですが、ユーザーCALは割とゆるふわ判定なのです... ↩︎
